14. 빈의 등록

빈의 등록

조회 빈이 모두 필요할 때

• Map , List 자료구조를 통해 초기에 bean을 만들 때 모든 빈을 해당 자료구조에 등록이 가능하다.
• 다양한 bean을 가지고 파라미터로 String beanName을 통해 적절한 빈을 꺼내와 다형성을 활용해 로직을 동적으로 설계할 수 있다.
  • 다형성 보장
  • DI 보장

자동이 좋을까? 수동이 좋을까?

편리한 자동 기능을 기본으로 사용

• 현재의 추세
• 스프링은 당연한 어노테이션을 제공한다.
  • @Component , @Controller , @Service 등 자동 스캔을 지원
• 이런데도 불구하고 @Configuration 설정 정보에서 수백개의 Bean을 관리하기는 쉽지 않음
• 자동 빈을 등록해도OCP, DIP를 지킬 수 있다.

언제 수동 빈 등록을 사용해야할까?

• 어플리케이션 업무 로직과 기술 지원 로직
• 업무 로직 빈 : 일반적인 DAO 나 컨트롤러 같은 업무 로직에 개발 추가 할 때 추가 한다.
• 기술 지원 빈 : 기술적 문제 처리, DB 연결, 로그 처리 업무 로직 지원을 지원

업무 로직 빈

• 패턴이 존재
• 자동 기능을 사용하면 문제의 원인을 파악하기 쉬움
• 즉 자동을 권장

기술 지원 로직 빈

• 업무 로직과 비교해 수가 매우 적음
• 어플리케이션의 넓은 범위에서 적용
• 즉 추후 버그 찾기가 쉽게 하기 위해 수동 빈 등록을 통해 명확하게 들어남
  • 기술 지원 로직이 잘 적용 되는지?
  • 어디가 문제인지?

결론 : 어플리케이션 광범위하게 펼치는 기술 지원 로직 빈은 수동 빈으로 등록 해서 추후 유지보수에 좋게 하는 것이 좋다.

비즈니스 로직 중 다형성을 적극 활용할 때

• 인터페이스를 사용해서 비즈니스 로직에서 어떤 Bean이 사용 될지는 한눈에 알기 힘들다.
• 각 빈의 이름, 빈의 설정을 파악하기 어려움
• 이런 경우 수동 빈 등록이나, 자동으로 할시에 특정 패키지에 묶어 두는 것이 좋다. ‘

@Configuration
@ComponentScan(
        basePackages = "hello.core.member",
        excludeFilters = @ComponentScan.Filter(type = FilterType.ANNOTATION, classes = Configuration.class)
)
public class AutoAppConfig {
    
    @Bean
    public DiscountPolicy rateDiscountPolicy() {
        return new RateDiscoutPolicy();
    }
    
    @Bean
    public DiscountPolicy fixDiscountPolicy() {
        return new FixDiscountPolicy();
    }
}

• 이런식으로 하는게 한눈에 빈의 이름은 무엇인지… 어떤 빈이 주입될지 알 수 있다.
• 추상화는 내가 하면 좋지만 남이 알아보기 힘들다.
• 특정 패키지에 DiscountPolicy 의 구현 빈만 모아두면 자동 등록도 좋다.

스프링과 스프링 부트가 자동으로 등록하는 수 많은 빈들은 예외

• 얘들은 그냥 자동으로 되게 내버려둔다.
• 직접 스프링 지원 객체는 수동이 좋긴하다…

결론

• 자동 기능을 디폴트로 둔다.
• 기술 지원 객체는 수동으로 한다.
• 다형성이 들어갔다면 수동도 고려 대상이 될 수있다.